If you make it a warnings.warn instead of print it allows downstream users to filter on it

Right, much better.
Will include in upcoming commit.

But perhaps a RunTimeWarning should not be raised here, since the beam can be filled in "further down the line".

Do we expect the user to update the beam conf after creating the object? If so we could decide to define a property getter that raises a warning if some parts of the beam are None, but at least the way I use it now is that I define the pyse conf before calling pyse functions and do not modify that afterwards. Is there a usecase where this does happen?

I was thinking of this use case:

some_im = sourcefinder_image_from_accessor(FitsImage('test/data/image_206-215-t0002.fits', 
beam=(0.208, 0.13, 15.619)))

Ah I see. In that case I think we can cover this by adding a similar warning here:

Or you could remove all usages of the beam as a function argument and use the info in ImgConf instead. Then you could add a property to the ImgConf that looks someting like:

@dataclass(frozen=True)
class ImgConf(_Validate):
    bmaj: float | None = None              # Set beam: Major axis of
    # restoring beam (degrees).
    bmin: float | None = None              # Set beam: Minor axis of
    # restoring beam (degrees).
    bpa: float | None = None               # Set beam: Restoring beam position
  
    @property
    def beam(self):
        beam = (self.bmaj, self.bmin, self.bpa) 
        if None in beam:
             warnings.warn(("Partial beam specification ignored; "
                 "one or more of (bmaj, bmin, bpa) are not "
                 "specified."), RuntimeWarning)
             return None
        return beam

Which you can then reference like conf.image.beam. But with this approach passing the beam like you do in this example does not make sense anymore because it then needs to be part of the config object:

some_im = sourcefinder_image_from_accessor(FitsImage('test/data/image_206-215-t0002.fits', 
beam=(0.208, 0.13, 15.619)))

So the way I see it you can either handle the beam in one place but break the current API or keep support for the keyword arguments in functions but perform check in multiple locations

So the way I see it you can either handle the beam in one place but break the current API or keep support for the keyword arguments in functions but perform check in multiple locations

Thanks for elaborating. I am inclined to choose the latter, because beam is a special case in the sense that can it can be derived from an ImgConf object or extracted from a FITS image header / CASA table header.
For that reason, I think that maintaining the option of overriding beam is not bad.

In that case I think we can cover this by adding a similar warning here:

Thanks. Will include in upcoming commit.

Ah I see. In that case I think we can cover this by adding a similar warning here:

But then, since the image module is the "end point", shouldn't a RunTimeWarning there suffice, i.e. adding it anywhere else would be redundant?

Yeah I think you are right. That would also solve it then :)